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REMARKS 

In response to the final Office Action mailed July 7, 2005, Applicants 
respectfully request entry of the amendments herein and reconsideration of this 
application in view of these amendments and the remarks below. It is 
respectfully submitted that the amendments herein place this application in 
condition for allowance, as explained below, or alternatively place the application 
in better form for appeal if that should be necessary. In this amendment, claims 
have been either cancelled, re-written in independent form, or amended to be of 
commensurate scope with the re-written dependent claims Accordingly, no new 
issues requiring further reconsideration and/or search are raised by this 
amendment. 

Claims 2-4, 6-1 1,13-15 and 17-30 were pending in this Application. By 
this Amendment, claims 2, 6, 13, 17, and 23-26 have been canceled. Applicants 
expressly reserve the right to prosecute at least some of the canceled claims and 
similar claims in one or more related Applications. Claims 27-30 have been re- 
written in independent form, and claims 9-1 1 and 20-22 have been amended to 
include all the features recited in claims 27-30. Claims 3-4, 7-11, 14-15, 18-22 
and 27-30 are now pending in this Application. Claims 9-1 1 , 20-22 and 27-30 
are independent claims. 

Rejections under 35 U.S.C. § 112 
In the Office Action, claims 27-30 are rejected for reciting both RTSP 
packets as well as RTP packets. However, these claims recite that the network 
traffic is RTSP traffic, the first data element is an RTP packet, and the second 
data element is an RTCP packet. As explained on page 1 of the application as 
filed, both RTP and RTCP are used within RTSP - an RTSP session includes 
five channels, one of which is a TCP channel, two of which are RTP channels, 
and two of which are RTCP channels. Thus, where these claims recite the RTP 
packets, they are referring to the packets of one of the RTP channels, and not to 
the overall RTSP session. It is believed that this explanation is sufficient to 
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overcome this rejection. If the Examiner should disagree, he is invited to suggest 
alternative claim language that may be acceptable. 

Rejection under S 103 
In the Office Action, the claims were rejected under 35 U.S.C. § 103 as 
being unpatentable in view of Cunningham and certain statements in the 
Background of this application. It is noted that previous independent claims 2, 6, 
13, and 17 have been cancelled in favor of previous dependent claims 27-30, 
which have been re-written in independent form, and the other independent 
claims have been amended to include the same features recited in claims 27-30. 
This rejection is respectfully traversed with respect to the claims as amended 
herein. 

The pertinent teaching of Cunningham and the Background are 
summarized in the last response dated June 15, 2005, and are not repeated here 
except as necessary in the arguments presented below. 

All the independent claims of this application now recite specific structure 
and use of the entries in the network address translation (NAT) data structure, as 
well as the pertinent structure and operation of the RTP and RTCP 
protocols/packets of an RTSP session. In particular, as pointed out in the 
previous response, these claims specify the creation and use of two NAT entries 
including respective first and second port numbers that are mutually distinct but 
have predetermined relationships as established by an RTSP session. The 
example given in the application is that the port number for the RTCP data flow is 
one greater than the port number for the RTP data flow, in accordance with 
standard RTSP practice. In particular, the two NAT entries are both created 
concurrently in response to receipt of an RTP packet. Thus, upon receipt of an 
RTP packet of a first data flow of the RTSP session (e.g., the video channel), the 
NAT data structure is populated not only with a first entry that is used to carry out 
the address translation for the RTP packets, but also with a second entry that is 
used to carry out the address translation for RTCP packets that are subsequently 
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received, which is an entirely separate flow. As described in the specification, 
this operation avoids the potential discarding or mis-routing of RTCP packets due 
to the absence of a NAT entry and the resulting random assignment of the RTCP 
flow to a server. By creating the second entry of the NAT data structure upon 
receipt of the RTP packet, the system is ready to correctly perform address 
translation for the subsequent RTCP packets so that they are reliably sent to the 
correct server (i.e., the same server that sent the RTP packet). 

It is emphasized that in the claimed technique, network address 
translation is performed on the basis of both addresses and port numbers, as set 
forth in the claims in some detail. In an example shown in Figure 4 of the 
application, an exemplary first entry 92-1 will cause a packet from a first network 
with a source address/port of 3.3.3.3/6970 and a destination address/port of 
1.1.1.1/5555 to have its source address/port translated to 2.2.2.2/6970. This 
entry is specific to packets having a source address/port of 3.3.3.3/6970; it is not 
utilized for packets having a different source port number, even if the source 
address matches. In the claimed technique, address translation is riot performed 
on the basis of the source address alone. Rather, both the source address and 
the source port number of a packet are translated based on a match of both the 
source address and source port number with the corresponding fields of a NAT 
entry. 

It is further noted that the above method of performing network address 
translation (i.e., based on both source address and source port number) has 
particular implications when used in the context of a multiple-server network such 
as shown in Figure 1 of the application. The NAT entries for different servers will 
all utilize the same proxy address (e.g., the network address 2.2.2.2 of the 
communications device 28), and include respective distinct port numbers to 
distinguish among the different servers (e.g. among servers 24-1, 24-2, ...). 
Thus in the illustrated embodiment, the communications device 28 might map the 
address/port pairs for respective RTP flows of the servers 24-1 and 24-2, for 
example, to translated address/port pairs such as 2.2.2.2/6970 and 2.2.2.2/7000, 
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where the different port numbers 6970 and 7000 enable the device 28 to identify 
which server 24-1 or 24-2 is the source of RTP packets received from the second 
network. This operation is in addition to the use of distinct port numbers for the 
different constituent channels or flows (RTP and RTCP) of a single RTSP 
session of only one server 24. Thus, an entity performing NAT according to the 
claimed technique (such as device 28) is constrained in how it may use port 
numbers to identify different servers - it cannot use any port numbers that are 
used to create any "second entries" for RTSP sessions. Given that an RTSP 
may have four UDP channels (one RTP/RTCP pair for video, and one pair for 
audio), a device might allocate groups of four successive port numbers to 
different servers, for example. 

In view of the above, it is hoped that the significance of the claimed 
technique of automatically creating a second entry having a distinct port number 
is appreciated. The second entry is not utilized for packets that are part of the 
first flow of the RTSP session (i.e., the RTP traffic), but rather is utilized for 
packets that are part of the separate second flow of the session (the RTCP 
traffic). Moreover, the use of such a distinct port number for such a related flow 
must be coordinated with the more general use of port numbers to identify 
different servers when NAT is performed using address/port pairs as set forth in 
the claims. 

It is respectfully urged that neither Cunningham nor the Background 
teaches or suggests such functionality. In particular, neither Cunningham nor the 
Background teaches or suggests two concurrently created NAT entries including 
respective first and second port numbers that are mutually distinct but have 
predetermined relationships as established by an RTSP session. Cunningham 
shows a completely different way of performing network address translation, 
which is based on using a large pool of globally unique addresses that are 
selected when necessary and mapped to local host addresses. There is no use 
of port numbers for purposes of address translation shown in Cunningham. 
Moreover, Cunningham clearly doesn't teach or suggest any technique for 
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concurrently creating and using NAT entries having distinct-but-related port 
numbers to handle multiple channels of a single RTSP session. Column 18 lines 
28-32 of Cunningham, which is referred to in the Office Action, is understood to 
mean only that Cunningham's technique may be utilized as described in 
connection with various types of protocols, but not to suggest that it be used in 
any particular way in connection with the two distinct protocols (RTP and RTCP) 
of separate channels of a single RTSP session, nor to suggest that it be 
somehow modified to operate with port numbers as set forth in the claims. 

Thus it is respectfully submitted that Cunningham and the Background do 
not render the claimed invention obvious under 35 U.S.C. § 103. To begin with, 
these references are essentially incompatible, because they perform NAT in 
different ways. As described above, Cunningham teaches only the creation and 
use of NAT entries for distinct flows utilizing mappings of local addresses to 
globally unique addresses, and does not perform any kind of port-based address 
translation. The Background describes a gateway device that performs network 
address translation for packets of the different channels of an RTSP session 
using different port-based NAT entries created at different times. Cunningham 
does not teach or suggest any extension of its NAT technique to incorporate port 
numbers, nor does the Background remotely suggest incorporating an entirely 
separate NAT technique based on global addresses such as shown in 
Cunningham. It is not seen how or why the teaching of Cunningham would be 
modified to include the teaching of the Background, given their different 
approaches to network address translation. 

Moreover, even if the teaching of these references were somehow 
combined, there is still no teaching or suggestion to concurrently create two 
separate NAT entries with distinct-but-related port numbers upon receiving an 
RTP packet, such that subsequently received RTCP packets are reliably routed 
to the correct server. Cunningham shows only the concurrent creation of two 
entries that utilize the same global address, in order to perform address 
translation for both directions of a single flow. The Background describes only 
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the normal result of conventional NAT in the context of a server farm and multiple 
independent flows, which is that separate NAT entries (created non-concurrently) 
direct the flows to different servers. There is no teaching or suggestion in these 
references, either separate or together, of concurrently creating two NAT entries 
with distinct-but-related port numbers to correctly handle the multiple channels of 
an RTSP session. Because this aspect of the claimed invention is entirely 
absent from both Cunningham and the Background, these references cannot 
render the claimed invention obvious under 35 U.S.C. § 103. 

Based on the foregoing, it is respectfully submitted that all the claims of 
this application are allowable over Cunningham, the Background, and the other 
art of record. Favorable action is respectfully requested. If there are any issues 
remaining after this amendment, the Examiner is urged to telephone the 
undersigned attorney to resolve such issues to enable this application to 
expeditiously proceed to issuance. 

Applicants hereby petition for any extension of time which may be required 
to maintain the pendency of this case. If there is a fee occasioned by this 
response, including an extension fee, that is not covered by an enclosed check, 
please charge any deficiency to Deposit Account No. 50-0901 . 

If the enclosed papers or fees are considered incomplete, the Patent 
Office is respectfully requested to contact the undersigned collect at (508) 366- 
9600, in Westborough, Massachusetts. 
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